@RalfJung is using offset to create a pointer one past the end of the allocation allowed? This caught my eye when adding safety comments; the docs say "the entire memory range between self and the result must be in bounds of that allocated object" and Miri doesn't complain, but I had been thinking that it was at least indeterminate (and now I can't find the issue).

If an allocation has size 4, and a ptr starts at offset 0 and you add 4 to it, then the memory range between the old and new pointer has size 4. Clearly that is entirely inbounds. Not sure what you mean by "indeterminate" here -- we don't use that word in Rust, and in C it is used to refer to values/representations, not operations, so I can't make sense of it here.

I think "one past the end" is bad terminology, since the pointer is not past the end, it is at the end -- it points after the last element.

Yeah that's straightforward enough. I must be misremembering; I thought there was an open issue somewhere related to differences between Rust and C here regarding creating a pointer past (or at) the end of an allocation and how that related to memcpy, but maybe this was only about wrapping at the end of the address space.

Not sure what you mean by "indeterminate" here -- we don't use that word in Rust

Indeterminate only because it had not yet been decided, not technical terminology.

I'm probably thinking of rust-lang/unsafe-code-guidelines#465 and related discussion, which has been decided and I'm just a year out of date :) So as I understand it, a Rust program can never access the last byte of the address space and that effectively means our memcpy doesn't have to worry about it - with the result that these offset calculations will never wrap.